home *** CD-ROM | disk | FTP | other *** search
/ Internet Toolkit / Internet Toolkit.iso / info / ircrule / text0000.txt < prev   
Encoding:
Text File  |  1993-06-30  |  8.7 KB  |  225 lines
  1. This is the set of rules for the.PLAN as they now stand.  additional
  2. commentary would be appreciated.
  3.  
  4. Rules for Opers in the.PLAN
  5.     -Jennifer Wesp     (July 1991)
  6.  
  7. The "enforcement" of these will continue much as it has been.  Talk
  8. to the oper in question if there is an oper related problem, or mail
  9. the server admin if the trouble is with the server.  (If the oper
  10. ignores you then also go to the server admin) The only "new" idea is
  11. that a stronger emphasis should be placed on the next server up the
  12. line, if the admin of the server that is a problem proves unhelpful.
  13. The last line of recourse is to request of the links to the "bad"
  14. server that the links be cut.
  15.  
  16. 1) No kills.
  17.    *Exceptions:
  18.     Ghosts.
  19.     Evading Ignore.
  20.     "Stealing" chanop.
  21.  
  22. 2) No squits.
  23.    *Exceptions:
  24.     You can squit links to your own server, but if you
  25.     need to squit one you should probably rethink your
  26.     Y: lines.
  27.     You can squit to fix a routing that puts Europe in
  28.     the middle of two groups of US servers. (or Japan,
  29.     or Australia...)
  30.  
  31. 3) No wallops.
  32.    *Exceptions:
  33.     Discussion of impending squits.
  34.     Discussion of impending Q: lines, suspected hacked
  35.     servers, or other things that are prohibitted.
  36.     The majority of the discussion should go to a
  37.     channel, however.
  38.  
  39. 4) No Walls.
  40.    *Exception:
  41.     War has broken out, the Big One hit California, or
  42.     there is a large meteor on it's way.  There should
  43.     be only one wall in such an event.
  44.  
  45. Commentary by Greg Lindahl:
  46.  
  47. 1) KILL is fairly useless these days. With an autoreconnect
  48.    client, for example, it's impossible to keep someone off of
  49.    IRC by killing them repeatedly. You'll piss off all the
  50.    other operators long before you stop the bad guy. Likewise,
  51.    if someone has a hacked server that allows them to steal
  52.    channel op repeatedly, or evades /ignore of user@host
  53.    repeatedly, killing them a bunch won't help. Killing them
  54.    once might send a message, but if they persist, a complaint
  55.    to a server or site administrator will be much more
  56.    effective than other measures.
  57.  
  58. Other sorts of things (i.e. being rude on a channel) should be
  59. dealt with by channel operators. That's what they're for. We
  60. hope to add /disinvite soon.
  61.  
  62. 2) With the new routing plan, SQUIT will not be needed as much.
  63.    An SQUIT of a major link causes a lot of network traffic,
  64.    and inconveniences the users. Properly designed routing
  65.    means that most of the time, routing will look good -- it
  66.    becomes a statistical process, and we're using the connect
  67.    frequencies as weights to bias the process towards the Right
  68.    Answer. So, no squits.
  69.  
  70. 3) There is a wide difference of opinion what wallops are for.
  71.    If you want to hold a conversation with a lot of operators,
  72.    you're probably better off using a channel and issuing a
  73.    single wallops advertising the disucssion. Remember that
  74.    LOTS of silent operators are on-line at any one time and
  75.    many of them won't be interested in what you have to say.
  76.  
  77. 4) Think of WALL as the equivalent of posting to
  78.    news.announce.newgroups -- you don't want to abuse it
  79.    because you don't want everyone to start ignoring all walls.
  80.    Again, there is a difference of opinion about this. But I
  81.    think that the vast majority think that walling birthdays,
  82.    for example, is a bad idea. This doesn't even begin to
  83.    address situations such as IRC users who don't speak english
  84.    getting walls in english, or someone walling happy birthday
  85.    in Swahili, Japanese, Russian, and 19 other languages to
  86.    make sure that everyone can understand it.
  87. ######
  88.  
  89. Rules for servers
  90.     -Jennifer Wesp (Phaedrus)    July, 1991
  91.  
  92. The "enforcement" of these will continue much as it has been.  Talk
  93. to the oper in question if there is an oper related problem, or mail
  94. the server admin if the trouble is with the server.  (If the oper
  95. ignores you then also go to the server admin) The only "new" idea is
  96. that a stronger emphasis should be placed on the next server up the
  97. line, if the admin of the server that is a problem proves unhelpful.
  98. The last line of recourse is to request of the links to the "bad"
  99. server that the links be cut.
  100.  
  101. 1) No server-open servers.
  102.    
  103.    *Consequently it is BAD to give links that are not for
  104.     servers that are in constant use, because then anyone
  105.     can set a server up that has access to that machine and
  106.     connect to you, if the "right" server is not around.
  107.     Also, infrequently used links should be passworded.
  108.  
  109. 2) No "hacked" servers.
  110.  
  111.    *This includes at least:
  112.     Servers that record messages in any way such that
  113.       anyone save the intended recipients can read them.
  114.     Servers that give channel op to anyone other than the
  115.       person who started the channel, or any subsequent
  116.       people that were given channel op by other channel
  117.       ops.
  118.     Servers that generate any false message, ie fake server
  119.       kills, squits, nick changes, etc.
  120.  
  121. 3) All servers must be within one major version of current.
  122.  
  123.    *This assumes (so far with reason) that major version
  124.     changes will cause incompatibility with old servers,
  125.     and that is to be minimised.  Also that administration
  126.     of a given server should be able to upgrade it every
  127.     4-5 months, or it can be considered defunct.
  128.  
  129. 4) No destructive testing of the network.
  130.  
  131.    *This includes at least:
  132.     KillBots that generate repeated kills
  133.     Any change to servers that disrupts traffic flow for
  134.       any server other than the one in question.
  135.     AutoReconnecting Clients without time delays.
  136.     Q-lining without ALL superhubs doing it simultaneously,
  137.       along with a majority of the hubs.
  138.  
  139. 5) No more than one server per site.
  140.  
  141.    *Assuming that one server can provide adequate coverage for
  142.     at least one site.  If this is not so then adding a new
  143.     server or moving the old one can be discussed.  Our first
  144.     priority is serving users, not creating servers just so
  145.     more people can be operators.
  146.  
  147. Commentary by Greg Lindahl:
  148.  
  149. 1) This is a security issue we haven't dealt with much in the
  150.    past; however, someday someone is going to hack a nameserver
  151.    just to use an unused, unpassworded link. An ounce of
  152.    prevention, etc.
  153.  
  154. 2) The major controversey here is whether or not it's "ok" in
  155.    some circumstances to create channel ops when none are
  156.    present.  I think not, for 3 reasons:
  157.  
  158.  A) It's only appropriate when everyone on the channel agrees.
  159.     There are some users who don't like channel operators and
  160.     avoid channels which have channel operators. So it's unfair
  161.     for them to join (or even create) a channel with no channel
  162.     operators, and see the rules changed before their very eyes.
  163.  
  164.  B) It gets abused when it exists. This is an unfortunate
  165.     reality.
  166.  
  167.  C) It's yet another special thing that an operator can do.
  168.     We're trying to make operators have as few special powers
  169.     as possible.
  170.  
  171. 3) We can't move forward unless people keep up. Running an IRC
  172.    server, unfortunately, takes a relatively large committment
  173.    of time. Someday it won't, but for now... for example, the
  174.    implementation of /disinvite that I have in mind won't work
  175.    until everyone upgrades. The ^G bug won't be history until
  176.    everyone patches or upgrades. Mode +n didn't work until
  177.    everyone upgraded. And so on.
  178.  
  179. 4) There is an alternative net for experiments, if you need to
  180.    do so.  The main IRC net should be considered a "production"
  181.    system, mainly here so people can talk to each other.
  182.    Putting in some Q-lines in some places results in a network
  183.    split, which means people can't talk. Bad.
  184.  
  185. 5) Some people claim that everyone has the RIGHT to be an
  186.    operator, because it's a privledge. I think it's the other
  187.    way around: being an operator is a burden, should be used
  188.    for technical reasons, and should be open to individuals who
  189.    have the technical knowledge to use it.
  190.  
  191. Likewise, it's not efficient for there to be one server per
  192. user. IRC has a large amount of overhead to support a server.
  193. Since we can serve people remotely, it's better to have fewer
  194. servers and more users per server.
  195.  
  196. ######
  197.  
  198. Rules for Superhubs
  199.     -Jennifer Wesp    (July 1991)
  200.  
  201. 1) Superhubs work as a group.
  202.    
  203.    This means that all policy decisions must be agreed upon
  204.    by all Superhub admins.  In case of an unresolvable
  205.    problem that requires action the minority should resign
  206.    if it finds it cannot agree with the action to be taken.
  207.    I would assume, however, that this should never be
  208.    required. (Refers to Q: lining, link cutting, adding new
  209.    code, and anything else where inconsistency across a
  210.    high traffic link will cause trouble.)
  211.  
  212. 2) Superhubs are expected to be patched within 24hrs notice
  213.    as required.
  214.  
  215.    This means that multiple people <must> be knowledgable
  216.    enough and available enough to be around pretty much all
  217.    of the time, and d owhat needs to be done.  a suggested
  218.    method for this would be to, if possible, give another
  219.    active admin access to the server code and .conf of your
  220.    server.
  221.  
  222.  
  223. -jennifer
  224.  
  225.